1. Field of the Invention
The invention relates generally to packet header compression and, more particularly, to replacement of the transport layer checksum in a packet header compression algorithm.
2. Description of the Related Art
The tremendous success of the Internet has made it desirable to expand the Internet Protocol (IP) to a wide variety of applications including voice and speech communication. The objective is, of course, to use the Internet as a link for transporting voice and speech data. Speech data is presently transported over the Internet using IP-based transport layer protocols such as the User Datagram Protocol (UDP) and the Real-time Transport Protocol (RTP). In a typical application, a computer running telephony software converts speech into digital data which is then assembled into data packets suitable for transport over the Internet using the IP-based transport layer protocols. Additional information regarding the UDP and RTP transport layer protocols may be found in the following publications: Jon Postel, User Datagram Protocol, DARPA RFC 786, August 1980; Henning Schulzrinne et al., RTP: A Transport Protocol for Real-time Applications, IETF RFC 1889, IETF Audio/video Transport Working Group, January 1996.
A typical packet 10 conforming to the IP-based transport layer protocols, such as UDP and RTP, is shown in FIG. 1. The packet 10 is one packet in a plurality of related packets that form a stream of packets representing, for example, speech data being transferred over a packet-switched communication network such as the Internet. In general, the packet 10 may be made of a header section 12 and a payload section 14. The header 12 may have a number of header fields, as shown, including such fields as the source and destination addresses of the packet 10.
FIG. 2 illustrates a pertinent portion of an exemplary packet-switched communication network 20. A packet source 22, such as the Internet, provides a stream of packets 10 across a link 24 to an access technology 26. The access technology 26 may be any layer of communications protocol, such as the Global System for Mobile Communications (GSM), Time Division Multiple Access (TDMA), and Wideband Code Division Multiple Access (WCDMA), that provide access to a receiver over a radio interface. The access technology 26 processes the packets 10 for transmission over a link 28 to a receiver 29 such as, for example, a mobile unit. The link 28 may be any radio interface, such as a cellular link, between the access technology 26 and the receiver 29. The receiver 29 receives the packets 10 from the access technology 26, processes them, and forwards them to their intended application, for example, a speech codec.
With pure speech data packets, however, the transport layer header 12 may represent up to 70% of the packet 10, leaving little capacity for the payload 14. For cellular links, this inefficient use of bandwidth prevents IP-based speech transportation from becoming an economically viable alternative to circuit-switched services. To make an IP-based solution for pure speech economically feasible over cellular links, the amount of bandwidth required for the header 12 must be significantly reduced. Therefore, some degree of header compression or reduction is required on a per-hop basis.
The term header compression refers to the art of transparently minimizing the bandwidth consumed by the information in the headers on a per-hop basis. In general, the headers are compressed or otherwise reduced at the transmitter or compressor side and then reconstructed at the receiver or decompressor side. Compression is made possible by virtue of a high level of redundancy in the headers, both within the same data packet and between consecutive packets. This redundancy allows the header values to be reliably predicted at the receiver based on expected incremental changes from packet to packet. As a result, some of the header information may be omitted during transmission, and then reconstructed at the receiver based on the expected values.
When starting transfer of a new stream of packets, only the static information and the initial values of the dynamic information in the transport layer headers are transmitted. The static information need not be transmitted again, but changes in the dynamic information need to be sent as they occur. By sending only the changes (as opposed to all header values), the bandwidth required for transmitting the headers may be significantly reduced. The headers may then be reconstructed by predicting their values based on expected incremental differences from the previous header values and as updated by the transmitted changes. Random or unpredictable information, however, cannot be reconstructed in this manner and is usually transmitted entirely as-is.
When transmitting data, in general, safeguards are implemented to ensure the data is received correctly. One method of safeguarding transmitted data is to employ an error detection check or code to detect data that has been corrupted or otherwise damaged during transmission. The error detection code is calculated (using one of several well-known methods) over the entire block of data to be protected and then included as part of the transmitted message. At the receiving side, a new error detection code is calculated over the received data and compared to the included error detection code. If the newly calculated error detection code matches the included error detection code, then the data has been received correctly.
One well known type of error detection code is called a checksum. Checksums are used, for example, by the UDP and RTP transport layer protocols to detect errors in a single data packet. Such transport layer checksums are calculated to provide coverage for the entire data packet (e.g., header and payload), and are included in the transport layer header as one of the header fields 16 (shown in FIG. 1). Calculation of the checksum is performed by adding together all the octets of data in the packet to be transmitted. A similar process is repeated at the receiver side, and the two sums are then compared for a match, which means the data have been received correctly.
However, checksums are understood by those of ordinary skill in the art to be among the weaker types of error detection codes. For example, while an error occurring in one of the octets may be detectable with a checksum, an error in two different octets would likely go undetected. As such, checksums are generally not used in high reliability applications such as header compression algorithms.
Because the transport layer checksums are generally considered to be too weak, most header compression algorithms generate a separate, stronger error detection check or code, such as a CRC (Cyclic Redundancy Code), to protect header information. For example, ROCCO (Robust Checksum-Based Header Compression) is one of several presently available header compression algorithms that employ a CRC. CRC calculation is well-known to those of ordinary skill in the art and will be described only briefly here. Basically, the block of data to be protected, such as the full original packet header, is divided by a polynomial having a predetermined length. The CRC is simply the remainder resulting from that division.
It has been suggested for header compression algorithms such as ROCCO that a CRC size of about 10 bits is sufficient. The size, of course, may vary on a case-by-case basis depending on the particular application of the algorithm. In addition, up to 6 bits of original, uncompressed header information (e.g., the delta values) may also need to be transmitted with the CRC for correct header reconstruction. This results in a minimum of 16 bits, or 2 octets, of header overhead that must be transmitted along with the compressed header.
Furthermore, as mentioned above, one of the fields 16 in the transport layer header is a checksum field. This field also occupies 2 octets in most cases and is used to verify the correctness of the transport layer packet. IP version 4 (IPv4) provides an option to disable the checksum, but doing so may make the data in the packet unreliable. There is no such disable option in the new IP version, IPv6.
Because both the CRC and the checksum types of error detection codes are essentially random in nature, transmission of these codes must be made as-is. Therefore, for IPv6 and most applications of IPv4, a minimum of 4 octets (2 octets+2 octets) of header overhead per packet is required in order to transport IP-based speech over a radio interface such as a cellular link. Accordingly, it is desirable to be able to reduce this header overhead by as much as possible, but without compromising the integrity of the data transported.
The present invention advantageously provides a method and apparatus for reducing the header overhead without compromising data integrity.
The present invention is directed to a method and apparatus for replacing a transport layer error detection code and a header compression algorithm error detection code with a single error detection code. The replacement error detection code covers both the transport layer payload and the transport layer header. Such an arrangement reduces the amount of as-is or uncompressed information transmitted, thereby reducing the required bandwidth. The replacement error detection code is subsequently used to verify the correctness of both the reconstructed header and the payload.
In one aspect, the invention is related to a method of replacing a transport layer error detection code in a header compression algorithm. The method comprises the steps of calculating one error detection code which covers both a transport layer header and a transport layer payload, compressing the transport layer header in accordance with the header compression algorithm, including the error detection code with the compressed transport layer header, and transmitting the compressed transport layer header.
In another aspect, the invention relates to a system for replacing a transport layer error detection code in a header compression algorithm. The system comprises an error detection code calculator for calculating one error detection code for both a transport layer header and a transport layer payload, a header compressor for compressing the transport layer header in accordance with the header compression algorithm, and a transmitter for transmitting the compressed transport layer header.